Description

Extends exporter support in declarative file configuration to handle custom (plugin) exporters across all three signals, matching the spec's PluginComponentProvider mechanism.

Solution

Each signal's factory function now has an exporter registry:

Known names (otlp_http, otlp_grpc, console) route to existing typed factory functions. Unknown names fall back to load_entry_point().

The generated models are unchanged. Python dataclasses don't enforce field types at runtime, so parent fields like BatchSpanProcessor.exporter naturally accept raw dicts (from the YAML loader) alongside typed instances. This preserves unknown plugin names as dict keys without diverging from codegen.

_parse_headers in _common.py is also updated to handle both NameStringValuePair objects (typed config path) and raw dicts (YAML path), making the full dict path testable.

Custom exporter example

tracer_provider:
  processors:
    - batch:
        exporter:
          my_custom_exporter: {}

[project.entry-points."opentelemetry_traces_exporter"]
my_custom_exporter = "my_package:MySpanExporterClass"

Remaining work

The OTLP factory functions still use typed attribute access (config.endpoint, etc.) internally. Converting them to accept raw dicts from the YAML loader is tracked in #5127.

Closes #5069